架空のシステムを題材にLambda or Fargateを検討するグループティスカッションを開催してみた

ちょと変わった勉強会？を開催してみました

#勉強会

岩田智哉

2022.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

MADグループ@大阪の岩田です。先日MADグループのメンバーで架空のシステムを題材にコンピューティング基盤としてLambdaとFargateのどちらを選定するか？というテーマでグループディスカッションというか勉強会というか...まあそんな会を開催してみました。せっかくなので内容について紹介します。

なぜやろうと思ったか？

きっかけはある案件の振り返り会です。API Gateway × Lamdaを利用したサーバーレスなアーキテクチャでバックエンドのAPIを開発していましたが、案件が進むにつれてLambda固有の辛みも色々と顕在化しだしました。今になって考えるとALB × Fargateの方が良かったんじゃないか？という意見もあり、Lambda/Fargateそれぞれのメリット・デメリットを議論するうちに時間がなくなり、不完全燃焼のまま振り返り会自体は終了となりました。

もう少ししっかり時間をとって、案件の背景や諸事情等は全て抜きにして純粋に技術面だけにフォーカスしてLambda/Fargateそれぞれのメリット・デメリットやアーキテクチャ選定の観点について議論できれば楽しそうだなと思ったのがきっかけです。

目的

MADグループメンバーのナレッジ共有を主目的に据えました。そのため、Lambda/Fargateどちらがマッチするのか特に正解を決めることはせず、○☓を付けたり各グループに順位を付けたりもしません。

ざっくりした流れ

以下のような流れで実施しました。Gatherを使って完全オンラインで実施しています。

架空のシステムを題材にグループごとにLambda or Fargateどちらを利用すべきかディスカッションしてもらう
各グループにはシステムの要件の一部のみが公開される
- 実案件でもアーキテクチャ選定段階で全ての要件が出揃っていないというのは良くある話なので、それをシミュレーション
- 多様な技術選定の観点を引き出すために、公開される要件はグループごとにバラバラにする
グループごとにLambda or Fargateの判断とその理由を発表してもらう
全グループの発表後、システム要件の全てを公開
改めてLambda or Fargateどっちが良いかをグループごとにディスカッションし、Lambda or Fargateの判断が変わったかどうかとその理由を発表してもらう

ディスカッション内容を一部紹介

当日のディスカッションの様子を一部抜粋してご紹介します。

要件

架空のシステムに設定した要件を一部抜粋してご紹介します(実際にはもう少し多いです)。ディスカッションの1回目ではグループごとにランダムに抽出した5つの要件を公開し、ディスカッションの2回目では全グループに全ての要件を公開しています。

B2CのECサイト
- ピーク時のアクティブユーザー数は60程度
- キャンペーンによるスパイクアクセスのようなものはなく、アクセス数は安定している
- 早朝、深夜のアクセスはほぼ0
商品点数は100程度
受注件数は100件/日程度
原則24時間365日稼働だが、可用性の要件はそこまでシビアではない
- SLAは95%以上を目指す
パフォーマンス要件はシビアではない。
- 各APIのレスポンスは平均3秒以内が目標
- 稀に5秒かかるとかは許容可能
ざっくり見積もりでAPIが100本ほど必要になりそう
クレジット決済に対応するためにアプリから外部サービスのAPIを呼び出す必要がある。
- 外部サービスのAPIはインターネット経由でアクセス可能
- 外部サービスのAPIを呼び出すためには事前に発行されたトークンが必要
デプロイにはカナリアリリースを使いたいと希望されている
ランニングコストの予算は月額$1,000以内
ある程度複雑なデータモデルを扱う必要がある
- RDBが必須

...等々

初回ディスカッションの様子

まずは各グループごとに5つだけの要件を公開した状態でLambda/Fargateどちらが適切かを議論してもらいました。

公開された要件だけだと不明点が多いので、アーキテクチャ選定のポイントになりそうな項目を列挙している様子です

こちらはLambdaとFargateそれぞれのメリット・デメリットについて議論している様子です

全要件公開後の再ディスカッションの様子

初回ディスカッションでは各グループに5つずつしか要件を公開していませんでしたが、全部の要件を公開したあとに改めてLambda/Fargateの意見が変わったかをディスカッションしてもらいました

色々な要件が追加で公開されたことで各グループLambda/Fargateの判断がより固まってきた印象です。

アンケート結果を一部紹介

会の終了後に参加メンバーにアンケートを取ってみました。現時点で10件の回答が集まっているので、回答内容の一部を要約してご紹介します。

ディスカッションを2回に分けて良かった？1回で良かった？

今回は実案件をシミュレーションする目的で全要件を公開しない状態で初回のディスカッションを実施してもらい、全要件公開後に2回目のディスカッションを実施してもらいました。このやり方については現状通り2回に分けるのが良いという票が8票、最初から全部の要件を公開した方が良いという票が2票でした。

現状通りが良いという回答には以下のような意見がありました ※一部抜粋&要約

メリット・デメリットについてより深く考えることができる
実際の案件でも、要件が見えないことが多々あるので、さまざまな要件視点から構成を考えていくのはものすごく面白いと感じた
1回目と2回目でLambda/Fargateの判断を変更した理由も気になる

逆に初回から全要件を公開した方が良いという回答には以下のような意見がありました ※一部抜粋&要約

段階的に公開するメリットがあまりわからなかった
要件を理解する速度は人によってばらつきがあるので、あらかじめ全ての要件を確認できる状態にしておいて、理解が遅い人でも時間をかけて追いつけるようにしてあげると良さそう。２段階だと、理解が遅い人が要件を理解するのにさらに時間がかかりそう

グループごとに別々の要件を公開するのは良かった？全グループ同じ要件を公開した方が良かった？

多様な技術選定の観点を引き出したかったので、初回ディスカッションの段階ではグループごとに別々の要件を公開していました。このやりかたについては現状通り別々の要件を公開するのが良いという票が6票、全グループ同じ要件を公開した方が良いという票が4表でした。

現状通りが良いという回答には以下のような意見がありました ※一部抜粋&要約

異なる観点での技術選定が見られるので良かったと思う
別の観点でディスカッションが行われていたので、他のグループからの共有がとても参考になりました。
ゲーム的要素も出て面白いと思ったので。

逆に全グループ同じ要件を公開した方が良いという回答には以下のような意見がありました ※一部抜粋&要約

短い時間でより深いディスカッションをするには、前提を揃えておいた方がコンテキスト理解の時間が短縮できそうだから
出てきたアーキテクチャがメンバーによる差と要件による差で変わってしまい、単純に比較しにくい。
他のグループとの考え方や設計の違いを比較しやすいため

参加して良かったと思いますか？

この質問には「はい」が10票集まりました。主催者としては一安心です。参加して良かった理由は以下のような意見がありました ※一部抜粋&要約

チームでアーキテクチャを相談するという機会が意外と少ないのでよい機会だと思った。
Fargate、案件であまり使ったことがないが、この会でいろいろ聞くことができた
バックエンドエンジニアの人のアーキテクチャ選定過程の議論に参加することはないので、非常に勉強になりました
コミュニケーションが取れる。メンバーがそれぞれどのような観点でアーキテクチャ選定をしているかを聞けて参考になった。
なんとなく持ってる技術選定でも、なぜそれを選んだかの言語化を改めてやってみると難しいことがわかった、考え直すきっかけになった
自分と違う技術を選んだ人の理由や視点が勉強になる

まとめ

ディスカッションを2回に分けたり、初回はグループごとに公開する要件をバラバラにしたり、少し変わったルールを設定した上でディスカッションを設定してみました。私は主催者という立場だったので、各グループのテーブルをグルグル周りながら色々な観点での意見を聞けたのがとても面白かったです。皆さんのチームや部署で勉強会を企画する際の参考になれば幸いです。